Skip to main content

Service Glossary

Here, in this section, we'll understand about the two options that the Product offers when you onboard a service. Also, we'll explore the Manual Build/Deploy option you need to choose while associating a service with an environment.

Once you’ve named the service, you can choose either of these to build,

  • Build Once and Promote
  • Build for every environment

Build Once and Promote#

Developers need to build only once in the Dev environment. They can build the code in one environment. Later, this code can be promoted to other higher environments such as QA, UAT, Staging and Production environments. If the code is successfully deployed in the Dev environment, it is sent to the QA environment. Now, users do not need to build again in the QA environment. They can simply deploy the existing code after applying CD checks. Later, this code can be promoted to other environments for deployment. With “Build Once and Promote”, developers do not need to trigger the build in every environment.

Build for Every Environment#

Here, development teams need to build and deploy the code separately for every environment. They can write code and then push this code in the Dev environment. After successful deployment in the Dev environment, teams have the ability to trigger a build in the QA environment and then deploy these builds. Similarly, every environment has separate branches consisting of source code. Teams can use these codes to run the build and then deploy the code as per custom-made CD checks. With “Build for Every Environment”, teams require different codes to trigger a build and deploy separately in each environment.

Manual Build & Deploy#

Manual Build & Deploy is a powerful and unique feature offered by BuildPiper. The product provides a choice to configure and enable manual build and deployment in any environment. While creating a new environment, users can choose to enable/disable Manual Build and Deploy via system setting available in Super Admin Portal. These environment settings automatically synchronise with the service creation settings during its association with that particular environment.

For instance,

Environment Creation

You create an environment “Dev” with Environment Name: Dev

  • Manual Build: No
  • Manual Deploy: Yes

Service Creation and its association with an Environment

Now, suppose you create a Service “TestService”. When you’ll associate this service with environment “Dev”, the settings will automatically have the same option as specified in the environment “Dev” as,

  • Manual Build: Not allowed
  • Manual Deploy: Yes

In lower environments, it's recommended to enable Manual Build and Deployment to enable quick builds and deployments. In higher environments such as UAT and production, usually, a series of gate checks and approvals will be required before the code can be deployed in those environments. If "Manual build/deploy" is opted for higher environments, then these tests and gate checks will get circumvented as these checks are applied in the pipelines. This is why Manual build/deploy feature is recommended to be disabled in higher environments.

System Level Configurations: For each environment, the Manual Build/Deploy feature is by default placed as either True or False, as shown below.

Docs Version Dropdown

Docs Version Dropdown